home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000256_connolly@pixel.convex.com _Tue Oct 27 23:52:34 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA08791; Tue, 27 Oct 92 23:52:34 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA25865; Wed, 28 Oct 92 00:04:34 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA23359; Tue, 27 Oct 92 17:03:46 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA18485; Tue, 27 Oct 92 17:03:41 -0600
  10. Message-Id: <9210272303.AA18485@pixel.convex.com>
  11. To: Larry Masinter <masinter@parc.xerox.com>
  12. Cc: NED@sigurd.innosoft.com, nsb@thumper.bellcore.com,
  13.         wais-talk@quake.think.com, www-talk@nxoc01.cern.ch
  14. Subject: Re: misconceptions about MIME [long] 
  15. In-Reply-To: Your message of "Tue, 27 Oct 92 14:38:18 PST."
  16.              <92Oct27.143829pst.101795@poplar.parc.xerox.com> 
  17. Date: Tue, 27 Oct 92 17:03:40 CST
  18. From: Dan Connolly <connolly@pixel.convex.com>
  19.  
  20.  
  21. >If I wish to retrieve the document, say to view it, I might want to
  22. >choose the available representation that is most appropriate for my
  23. >purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
  24. >from an anonymous FTP archive, only to discover that it is in the
  25. >newly announced Postscript level 4 format, or to try to edit it only
  26. >to discover that it is in the (upwardly compatible but not parsable by
  27. >my client) version 44 of Rich Text. In each case, the appropriateness
  28. >of alternate sources and representations of a document would depend on
  29. >information that is currently only available in-band.
  30.  
  31. What methodology do you propose to prevent this situation? It looks
  32. like a very hard problem indeed. But MIME makes a good stab at
  33. standardizing practices that are going on now. I think we can prevent
  34. further divergence in the CSCW and global hypermedia communities
  35. by adopting MIME now.
  36.  
  37. In short: I think MIME will not completely solve the problem you
  38. stated, but it _will_ do more good than harm.
  39.  
  40.  
  41. >I believe that MIME was developed in the context of electronic mail,
  42. >but that the usage patterns in space and time of archives, database
  43. >services and the like require more careful attention (a) to
  44. >out-of-band information about format versions, so that you might know,
  45. >before you retrieve a representation, whether you have the capability
  46. >of coping with it, and (b) some restriction on those formats which
  47. >might otherwise be uncontrollable.
  48.  
  49. The function you describe in (a) above is commonly known as the
  50. halting problem. No can do. Formats mentioned in (b) are called
  51. turing machines: postscript programs, excel macros, etc. And life
  52. gets only a little easier if you get rid of turing machines.
  53.  
  54. If I understand you correctly, every document must be annotated
  55. with all of the resources it requires. For example:
  56.  
  57. * TIFF image. 400x760. 16 colors (pantone #416, #450, #23, ...)
  58. zbar compression. 10k compressed. 160k uncompressed.
  59.  
  60. * postscript document. A4 page size. Peak virtual memory usage: 2.7mb
  61. on a LaswerWriter IINT. Fonts: courier (4-18pt), times, New Century Schoolbook.
  62.  
  63. * xwd image. 24 bit direct color image. Requires patch #18 on
  64. the RS/6000 X server.
  65.  
  66. I think MIME starts to look like a _very_ reasonable level of
  67. standardization given the possible spectrum.
  68.  
  69. Dan
  70.